Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/93mar/area.internet.93mar.txt

Text File | 1993-05-17 | 14KB | 355 lines

Internet Area

Directors (s):


   o Stev Knowles:  [e-mail]
   o Dave Piscitello:  [e-mail]


Area Summary reported by Dave Piscitello/Bellcore and Stev Knowles/FTP

Working Groups in the Internet Area are actively involved in the
development of Internet standards for:


  1. IP and multi-protocol operation over emerging wide area
     technologies (ATM, SMDS, Frame relay) and point-to-point
     technologies (including narrowband ISDN).

  2. Expanded use of the IP backbone by tunneling other widely used
     network protocols (Appletalk, SNA).

  3. Development of a ``next generation'' IP; i.e., a replacement
     protocol and addressing/routing architecture for IPv4;

  4. Miscellany (Dynamic host discovery, and multicast interdomain
     routing)


The following Groups in the Internet Area met during the Columbus IETF:


   o Birds-of-a-Feather (BOFS)
      -  Net Support for QOS and Real-Time Traffic
      -  SNA Peer-to-Peer Networking

   o Working Groups
      -  Dynamic Host Configuration
      -  IP Address Encapsulation
      -  IP over AppleTalk
      -  IP over Asynchronous Transfer Mode
      -  IP over Large Public Data Networks
      -  P. Internet Protocol
      -  Point-to-Point Protocol Extensions
      -  Simple Internet Protocol
      -  TCP/UCP over CLNP-addressed Networks


Four candidates for IPng (``next generation'', we are no longer
referring to this as IPv7)--PIP, SIP, and TUBA/CLNP,
ULLMAN/IPv7--provided plenary status reports and three provided
demonstrations throughout the week from the terminal room provided by
OARnet.  Many thanks to the participants for their efforts and to OARnet

                                   1





for their support.

SNA Peer-to-Peer Networking BOF (SNAPPER)

The SNAPPER BOF was held on April 1, 1993, and chaired by Wayne Clark,
cisco Systems, Inc.  Three alternatives for handling SNA peer-to-peer
(i.e., APPN) traffic across TCP/IP networks were presented:


  1. APPN over TCP/IP
  2. APPN/DLS using connection networks, and
  3. APPI


Pros and cons of the three alternatives were discussed and it was
decided that (a) the topic is too political at this point; (b) neither
IBM or the APPI Forum is ready to change at this point in time, and (c)
the APPN market at present is too small to worry about.

The conclusions of the BOF were:


  1. A data link switching (DLS) working group would be very desirable..
  2. Willingness to participate in the Working Group would be
     investigated.
  3. If the conditions of (2) are met, the [e-mail] mailing
     list would be used to develop a working group Charter and a more
     applicable name.


Dynamic Host Configuration Working Group (DHC)

The DHC Working Group discussed the interface between DHCP and the
Domain Name System (DNS). DHCP needs an interface that can allow dynamic
updates to DNS entries in response to dynamic allocation of DNS names to
DHCP clients.  Rob Austein explained that the DNS Working Group is
currently developing such an interface to DNS that considers the needs
of DHCP.

The Working Group discussed the possible use of SNMP with DHCP, to serve
as a ``second-level'' bootstrap mechanism to transmit additional
configuration parameters to a client.  SNMP is not likely to be as
useful as an implementation-specific interface for server management.
SNMP is an interesting candidate for the server-server protocol, as it
may provide the semantics and data representation tools required for
exchange of DHCP binding information between servers.

The Working Group discovered a technical problem with the current
definition of the `chaddr' field, which allows `chaddr' to be used as
either a hardware address or other unique identifier.  As the `chaddr'
value must be used to return DHCP reply messages to the client, that
field will be reserved for use strictly as a hardware address, and the


                                   2





client will be required to supply a unique identifier in a `client
identifier' option.  This identifier will be a typed value with the same
structure as defined for the `chaddr' field.

Mike Carney and Jon Dreyer submitted a new definition for encapsulating
vendor-specific options that the Working Group accepted with minor
modifications.  In the accepted definition, the `vendor- specific
information' option will include an initial value that identifies how to
interpret the contents of the option, and other DHCP options, encoded in
the same format as the current variable- length DHCP options.  The
initial identifying values will be centrally administered to avoid
conflicts.  One identifying value will be reserved for local use.

The mechanism for determining the parameters returned to a particular
client was discussed at length.  The focal points of the discussion were
the ways in which a client can identify its characteristics (`client
type' option) and the rules by which a server can use those
characteristics to choose the information to be returned to a host.  No
conclusion was reached at the meeting; an interim solution will be
incorporated into the DHCP specification Internet Draft to allow the
protocol to move forward to Proposed Standard.

IP Address Encapsulation Working Group (IPAE)

The IP Address Encapsulation (IPAE) Working Group met once during the
Columbus IETF. Since IPAE re-aligned itself to provide transition
technology for SIP, the foci of IPAE discussions have been:


  1. Modifications to SIP that are likely to facilitate transition, and
  2. Implementation experiences with SIP/IPAE.


(Reference to IPAE usage is specifically to SIP-over-IP and
SIP-mapped-to-IP. The first is to tunnel through the Internet and the
second is to gateway to IPv4 hosts.)

The Working Group held a brief discussion about the SIP/IPAE
demonstration slated for later in the week, discussing the
implementations being shown and their use.

Bob Gilligan, of Sun, and Ron Jacoby, of Silicon Graphics, discussed
their implementation work.  The Beame&Whiteside, Intercon, and Network
General, implementations, for DOS&Windows MacIntosh, and network
monitoring, respectively, were not available to make presentations.

Steve Deering raised the issue about whether SIP fragmentation is
end-to-end only, or can occur en-route.  He is interpreting the Group's
response as supporting the position that SIP fragmentation need *not*
occur en-route.

IP Over Asynchronous Transfer Mode Working Group (ATM)


                                   3





The IP over ATM Working Group met for three sessions at the March IETF
meeting, to discuss the following topics:


   o ATM Forum Addressing Work
   o Address Resolution in ATM Network
   o Architecture, Address Translation, and Call Control
   o NBMA Address Resolution Protocol (NBMA ARP)
   o General Discussion of ATM Address Resolution
   o Issues in the Interconnection of LANs and ATM Networks


Four presentations were given on ATM Addressing and ATM/Internet Address
Resolution.  Keith McCloghrie presented an overview of what the ATM
Forum addressing work.  Subbu Subramaniam presented his ideas on how ATM
address resolution should work.  Fong-Ching Liaw Presented pros and cons
of Subnet and Peer model of address resolution in ATM networks and Juha
Heinanen presented an overview of his NBMA Address Resolution Protocol
(NBMA ARP) proposal.

There was considerable discussion about how address resolution should
work, and pros and cons of the subnet vs.  peer model.  There were
strong views on both sides.  The session ended with suggesting that
neither one approach would prevail and proposed mechanisms for combining
the two approaches.  Mark Leabach presented slides with his thoughts on
which areas the Working Group should focus on first.  He saw two
approaches in the Working Group:  Functional layerists (ATM as a
wire-replacement) versus ATM IP Morph'ist.  He made a strong argument
that the Working Group should first specify how IP over ATM should work
in the ``classical IP'' mode where ATM networks are connected by
routers.  Mark went on to present a list of problems which need to be
solved.

Tim Salo presented a talk on the Gigabit Testbed Talk.  The goal of the
project is to create a seamless connection between ATM LAN's and ATM
WAN's.  His preliminary observations were that there are no complete
proposals available today, some ares only slightly explored or
identified, much new functionality must be implemented, and the most of
the problems are in the wide area.

His final observations were that we need a complete solution if ATM is
going to be the solution.  It is important to avoid making the customer
the system integrator.  Significantly more implementation experience is
needed.

Ramon Caceres presented the results of his simulation of different
approaches for VC multiplexing.  His conclusions were that one VC per
connection gives the best performance, followed by one VC per type of
traffic (e.g., telnet, ftp, mail, etc.).  One VC per router pair gives
poor performance.  The overall goal should be to separate traffic as
much as possible

After a final discussion of subnet versus peer addressing models, the
Working Group moved on to a discussion of important area to pursue and

                                   4





the assignment of action items to complete.

Joint IP over Large Public Data Networks Working Group (IPLPDN)
and Point-to-Point Protocol Extensions Working Group (PPPEXT)

The IP over Large Public Data Networks (IPLPDN) and PPP Extensions
(PPPEXT) Working Groups met in joint session to discuss protocol
specifications common to both.  Since the objectives and requirements of
the two working groups differ in some key respects, there was
considerable difference of opinion at the outset.

Two subjects were discussed:  how to share load among a set of parallel
links to increase apparent bandwidth and potentially reduce latency
between two sites, and how the IPLPDN group might best avail itself of
the facilities found in PPP negotiation.  Both Fred Baker and Keith
Sklower had proposals though the consensus was that Keith's approach was
preferred, but required some modifications.  Keith will appropriately
edit his proposal for further discussion on the IPLPDN mailing list.

The two Groups also discussed PPP Parameter Negotiation for Frame Relay.
Consensus was reached on several issues.  Keith Sklower and Bill Simpson
have agreed to merge their efforts and their current proposals to
implement this consensus.  The output will be discussed on the IPLPDN
list.

IPLPDN and PPPEXT expect to have two joint meetings at the Amsterdam
IETF.

IP over Large Public Data Networks Working Group (IPLPDN)

The revised draft of RFC 1294, ``Multiprotocol over Frame Relay,'' was
approved for submittal to the IESG for release in a new RFC and for
advancement from Proposed to Draft standard.

RFC 1356, ``Multiprotocol over X.25,'' was reviewed for advancement in
status.  It was agreed to perform tests of interoperability of
implementations.  The revised RFC 1315, the Frame Relay MIB document,
was discussed.  It was agreed to keep this document as the ``DTE MIB''
and that the new work on a Frame Relay MIB would become the ``DCE MIB.''

The Charter of IPLPDN: the Chair agreed to talk with the Area Directors
and with working group Chairs about the transfer of open issues to those
groups.  The Chair will report to the Group.

Work progressed on the ``Multiprotocol over Circuit ISDN'' document.
The draft was re-titled ``Encapsulation Determination for Circuit
Switched Services.''  Keith Sklower will incorporate comments and will
distribute the revised document by email for Working Group approval for
submittal to the IESG.

Two joint sessions were held with the PPPEXT Working Group.  Bill
Simpson and Keith Sklower were asked to co-author a ``Parameter


                                   5





Negotiation over Frame Relay and X.25'' document.

The P. Internet Protocol Working Group (PIP)

The PIP Meeting was tutorial in nature.  Paul Francis (formerly
Tsuchiya) covered various aspects of the Pip protocol, starting with the
header format and going through addressing.  No serious problems were
uncovered in the discussions, though Steve Deering did uncover a bug in
the proposed caching mechanism.

Attendees were invited to see a demonstration of PIP during the meeting.

Simple Internet Protocol Working Group (SIP)

The SIP Group discussed clarifications and changes to the SIP
specification ' since last November.  The most significant changes were
the addition of hop-by-hop options and the specification of
``local-use'' SIP addresses that hosts can fabricate from 802.11
addresses for the purpose of auto-configuration.  The group also
discussed a tentative SIP Sensitivity Label Option and a SIP End-to-End
Security Opti on, both based on recent work on IPv4 security.

The SIP Group also discussed proposed modifications to RIP-2, OSPF, and
IDRP to support SIP routing, as documented in recent Working-Group
drafts.  Finally, the Group received a status report on SIP ``host
routing'' work-in-progress.

TCP/UDP over CLNP-addressed Networks Working Group (TUBA)

The TUBA Working Group met to discuss the following topics:


   o Implementation Status and Demonstration.
   o Document Status.
   o Priortization of TUBA Work.

      -  Questions asked at Opening Plenary
      -  Dynamic Host Address Assignment
      -  Mobile Hosts
      -  Routing and Addressing Plan
      -  Transition Strategies
      -  Discussion of Technical Advantages of CLNP

   o Demo and Implementation Targets


Editor's Note (md):  A detailed summary of each topic is provided in the
Minutes which follow this Area Report.



                                   6